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© Data packets (96) are delivered through a con- 
stellation (11) of nodes (12) to a termination unit (18. 
20, 22). The node where a packet leaves the con- 
stellation is a terminal node. Each packet includes a 
routing code (100). When a node receives a packet, 
it examines the routing code to determine if that 
node might be the packet's terminal node. A table 
look up operation is performed using the routing 
code as an index to a routing table (54). The table 
identifies a link (16) to use in routing the packet 
away from the node to a neighbor node. The packet 
is also examined to verify compatibility between 
packet type and a selected link. When a node con- 
cludes that it might be a terminal node for a packet, 
it evaluates a channel identifier (102) to determine if 
it is currently serving the party to whom the packet 
is directed. 
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TECHNICAL FIELD OF THE INVENTION 

The present invention relates generally to com- 
munication networks. More specifically, the present 
invention relates to selecting paths for delivering 5 
communications through a network of switching 
nodes. 

BACKGROUND OF THE INVENTION 

70 

Communication networks, such as those used 
to deliver telecommunications, to interconnect com- 
puters, and the like, may include any . number of 
nodes. The networks may deliver electronic com- 
munications between two points by routing the 75 
communications from node to node within the net- 
work. As the number of nodes in a network in- 
creases and as the number of communication . 
paths available to each network node increases, the 
number of potential paths available for delivering 20 
any single communication likewise increases. Ac- 
cordingly, the problem of selecting an appropriate 
path through the network arises. Typically, a net- 
work attempts to select the shortest possible path 
to minimize delay, consume a minimal amount of 25 
network resources, and to maximize reliability in 
delivering a communication. At the same time, a 
network needs to balance this concern with a need 
to prevent communication traffic bottlenecks and a 
need to achieve the highest possible probability 30 
that a communication will be delivered to Its inr 
tended destination. 

Conventionally, a static communication delivery 
path through a network is established prior to the 
actual delivery of a communication. In other words, 35 
a static delivery path Is cleared during a call setup 
mode, which takes place before communications 
commence. A certain amount of network resources 
are dedicated to clearing the static path during call 
setup. However, once the static path has been 4o 
cleared it remains allocated to the upcoming call 
until the call terminates. 

While this conventional static signal routing 
technique adequately serves the needs of a static 
environment, It fails to meet the needs of a dy- 4S 
namic environment. In particular, when the network 
delivers communications between two points that 
move relative to the network, a dynamic path defi- 
nition is needed to compensate for movement. For 
example, the physical assets, or switching nodes. 50 
which are advantageous choices in routing signals 
between two points at call setup become disad- 
vantageous choices as the; call progresses due to 
movement. 



SUMMARY OF THE INVENTION 

Accordingly. It is an advantage of the present 
invention that a network is provided which dynam- 
ically routes communication signals. 

Another advantage of the present Invention is 
that network resources dedicated to routing com- 
munication signals are minimized. 

Another advantage is that the present invention 
distributes routing decisions among network nodes. 

Another advantage is that the present invention 
minimizes delay in delivering communication sig- 
nals between network entry and exit points. 

Another advantage is that the present invention 
compensates for communication traffic congestion. 

The above and other advantages of the present 
invention are carried out in one form by a method 
of routing a signal through a switch which serves 
as one node in a constellation of switching nodes. 
The method calls for receiving a data packet hav- 
ing a routing code therein. The data packet repre- 
sents at least a portion of the signal being routed. 
A link identifier is obtained in response to the 
routing code included in the data packet. This link 
identifier specifies one of a plurality of communica- 
tion links useable at the switch in routing the data 
packet away from the switch. The data packet is 
then transmitted away from the switch over this 
one communication link. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present 
invention may be derived by referring to the de- 
tailed description and claims when considered in 
connection with the Figures, wherein like reference 
numbers refer to similar items throughout the Fig- 
ures, and: 

FIG. 1 shows a layout diagram of an environ- 
ment within which an embodiment of the present 
Invention Is practiced; 

FIG. 2 shows a layout diagram of switching 
nodes in a communication network, jurisdictions 
corresponding to the switching nodes, and com- 
munication links between the switching nodes; 
FIG. 3 shows a block diagram of a single switch- 
ing node, or switch, of the communication net- 
work; 

FIG. 4 shows a flow chart of a Background 
, procedure performed by switching nodes of the 
communication network; 

FIG. 5 shows a flow chart of a Switch procedure 
performed by switching nodes of the commu- 
nication network; 

FIG. 6 shows a data format diagram used in a 
first embodiment of the present invention to 
communicate data; 
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FIG. 7 Shows a data format diagram used in a 
second embodiment of tlie present invention to 
communicate data; 

FIG. 8 shows a data format diagram used to 
convey a routing code; 

FIG. 9 shows a data format diagram used to 
convey a logical channel identification (LCID) 
value; and 

FIG. 10 shows a flow chart of a Terminal Node 
procedure performed by switching nodes of the 
communication network. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIME"NTS 

FIG: 1 illustrates a sate! lite- based communica- 
tion network 10. Network 10 includes a constella- 
tion 11 of switching nodes 12 that are dispersed 
around the earth. In the preferred embodiment, 
nodes 12 are orbiting satellites. Satellites 12 oc- 
cupy polar, low-earth orbits 14. In particular, the 
preferred embodiment of network 10 uses seven 
polar orbits, with each orbit holding eleven sat- 
ellites 12. For clarity. FIG. 1 illustrates only a few of 
these satellites 12. 

Orbits 14 and satellites 12 are distributed ar- 
ound the earth. Each orbit 14 encircles the earth at 
an altitude of around 765 km. Due to these low- 
earth orbits 14, satellites 12 travel with respect to 
the earth at around 25,000 km/hr and complete an 
orbit in around 100 minutes. Together, satellites 12 
remain relatively stationary within constellation 11 
with respect to one another, except for their orbits 
converging and crossing over each other in the 
polar regions. 

FIG. 2 presents an exemplary static, two di- 
mensional "snap-shot" map of the relative orienta- 
tion of a few of satellites (SVs) 12. With reference 
to FIGs, 1-2, at any given instant satellites 12 in 
even orbital planes 1 4a typically reside at approxi- 
mately the same latitudes. Likewise, satellites 12 
typically reside at approximately the same latitudes 
for all odd planes 14b. However, odd-plane sat- 
ellites 12 are positioned out-of-phase with even- 
plane satellites 12. At any given instant, the lati- 
tudes of odd^plane satellites 12 are approximately 
half way between the latitudes for nearby even- 
plane satellites 12. 

A line-of-slght exists between each satellite 12 
and fore and aft satellites 12 in the same plane 14 
and . between fore and aft satellites 12 in adjacent 
planes. With reference to FIG. 1, a line-of-slght also 
exists between satellites in non-adjacent orbital 
planes 14 as the orbits converge near the polar 
regions. The preferred embodiment employs RF 
communications, preferably in the 20-30 GHz 
range, to establish communication links 16 between 
each satellite 12 and its "neighbor" satellites 12. 



Links 16 are referred to as cross links herein to 
distinguish them from the links used by signals for 
entry into and exit from constellation 1 1 . With refer- 
ence to FIG. 2. up to six llne-of-sight, bi-directional, 

5 RF communication cross links 1 6 are supported for 
each satellite 12. Fore and aft cross links 16a and 
16b exist between a satellite 12x and the preceding 
and following satellites 12a and 12b, respectively, 
orbiting in the same plane 14 (I.e. In-plane sat- 

70 ellites). Fore-right and aft-right cross links 16c and 
16d exist between satellite 12x and the preceding 
and following satellites 12c and 12d. respectively, 
orbiting in a right side adjacent plane 14 (I.e. cross- 
plane satellites). Likewise, fore-left and aft-left cross 

75 links 16e and 16f exist between satellite 12x and 
the preceding and following satellites 12e and 12f, 
respectively, orbiting In a left side adjacent plane 
14. 

For purposes of the present Invention, satellites 
20 12a-12f are referred to as neighbor satellites to 
satellite 1 2x. In particular, neighbor satellites nodes 
are those constellation nodes to which messages 
may be sent and from which messages may be 
received without requiring the messages, to pass 
25 through any other node. This definition Includes 
nodes which may not be in adjacent orbital planes 
but which nevertheless are within a llne-of-sight 
due to the convergence of orbital planes 14 in the 
polar regions. In the embodiment of the present 
30. invention depicted in FIGs. 1-2, communications 
may be delivered only to neighbor nodes. Each 
satellite 12 supports a similar set of cross links 16 
and neighbor nodes. 

While FIGs. 1-2 and the above-presented dls- 
35 cussion describe a preferred orbital geometry for 
network 10, those skilled In the art will appreciate 
that the switching node which each satellite 12 
provides need not be positioned as described here- 
in. For example, such nodes may be located on the 
40 surface of the earth or in orbits other than those 
described herein. Likewise, the precise number of 
switching nodes may vary from network to network, 
the. number of cross links 16 supported by each 
node may vary from network to network, and the 
45 population of switching nodes, with which each 
node may directly communicate need not be limit- 
ed to nodes physically nearby. 

With reference back to FIG. 1. satellites 12 
communicate with devices on the ground through 
50 many central switching offices (CSOs) 18, of which 
FIG. 1 shows only one, a few ground control sta- 
tions (GOSs) 20, of which FIG. 1 shows only one, 
and any number, potentially in the millions, of radio 
communication subscriber units 22, of which one is 
55 shown in FIG. 1. Subscriber units 22 may be lo- 
cated anywhere on the face of the earth. CSOs 18 
are preferably distributed over the surface of the 
earth In accordance with geopolitical boundaries. In 
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the preferred embodiment, each satellite 12 may 
communicate with up to four CSOs 1 8 and over a 
thousand subscriber units 22 at any given instant. 
GCSs 20 preferably reside in the northern or south- 
ern latitudes, where the convergence of orbits 14 
causes a greater number of satellites 12 to come 
within direct line-of-sight view of a single point on 
the surface of the earth with respect to more equa- 
torial latitudes. Preferably, around two to four GGSs 
20 are used so that all satellites 12 in the constella- 
tion may at some point in their orbits 14 come 
within direct view of their assigned GCS 20. 

Nothing prevents CSOs 18 and GCSs 20 from 
being located together on- the ground. However, 
CSOs 18 serve a different function from that of 
GCSs 20. GCSs 20 preferably perform telemetry, 
tracking, and control (TT&C) functions for the con- 
stellation of satellites 12. 

Preferably, CSOs 18 operate as communication 
nodes in network 10. Diverse terrestrial-based com- 
munications systems, such as national public 
switched telecommunications networks (not 
shown), may access network 10 through CSOs 18. 
Due to the configuration of the constellation of 
satellites 12, at least one of satellites 12 is within 
view of each point on the surface of the earth at all 
times. 

For purposes of the present invention, each 
end of a communication may be viewed as having 
a terminal node. The role of a terminal node is 
played by the one satellite 12 in constellation 11 
that routes the communication away from constella- 
tion 11 toward the earth. The terminal node may 
deliver a communication to a CSO 18, a GCS 20, 
or a subscriber unit 22. 

Accordingly, network 10 may establish a 
bidirectional communication circuit or two unidirec- 
tional circuits through constellation 11 of satellites 
12 between any two subscriber units 22, between 
any subscriber unit 22 and any CSO 18, or be- 
tween any two CSOs 18. However, these commu- 
nication circuits use different nodes of constellation 
11 from moment to moment for delivering commu- 
nications. The nodes change in response to the 
movement of constellation 11 with respect to the 
earth. 

In addition to the above-discussed relationship 
between satellites 12 and cross links 16, FIG. 2 
shows two jurisdictional patterns related to sat- 
ellites 12. FIG. 2 shows a pattern of circles 24 
arranged so that each satellite 12 resides at the 
center of a circle 24, so that every point in FIG. 2 
resides within at least one of circles 24. and so that 
a minimal amount of overlap between circles 24 
results. Circles 24 roughly indicate lines of equal 
signal strength for RF communications broadcast to 
the surface of the earth from each corresponding 
satellite 12. Accordingly, circles 24 roughly define 



the geographical jurisdiction on the earth of each 
satellite 12. In other words, a CSO 18. GCS 20. or 
subscriber unit 22 may communicate with a sat- 
ellite 12 within whose jurisdiction it resides. Since 

5 satellites 12 move relative to the earth, circles 24 
likewise move. Those skilled in the art will appre- 
ciate that nothing prevents the division of circles 24 
into smaller cellular patterns to improve the geo- 
graphical reuse of the frequency spectrum allo- 

10 cated to each satellite 12. Moreover, those skilled 
in the art will recognize that the boundaries in- 
dicated by circles 24 are not defined with precision 
in actuality. 

FIG. 2 additionally shows a pattern of space 

76 regions 26. Each space region 26 is represented 
by a unique static hexagon. Regions 26 are static 
because they do not move with respect to the 
earth. Thus, satellites 12 and circles 24 enter and 
exit regions 26 due to the movement of satellites 

20 12. FIG. 2 illustrates space regions 26 as equal 
size hexagons having a diameter approximately 
equal to the diameter of circles 24. Thus, no signifi- 
cant overlap occurs between regions 26. and re- 
gions 26 collectively cover the entire surface of the 

25 earth. However, those skilled in the art will appre- 
ciate that any number of regions 26 may be de- 
fined, that other shapes may be adopted, that all 
regions 26 need not have the same shape or size, 
and that no set geometric relationship needs to 

30 exist between regions 26 and circles 24, For exam- 
ple, space regions 26 and circles may both be- 
come reduced in size near the polar regions to 
compensate for the convergence of the orbits. 

In the preferred embodiment of the present 

35 invention, approximately 77 space regions 26 are 
defined. Although this number achieves a desirat]|le 
one-to-one correspondence to the number of sat- 
ellites 12 in the preferred embodiment of the 
present invention, it is not a critical feature. On the 

40 other hand, a unique one of 77 possible space 
regions may be specified with a seven bit number, 
which is a relatively small amount of data to use in 
communicating world-wide geographic data. More- 
over, with 77 space regions approximately the 

45 same size as circles 24, each space region 26 fits 
within the collective jurisdiction of a particular one 
of satellites 12 and the neighbor satellites to this 
one satellite 12. 

Circular patterns 24 and space regions 26 are 

50 useful because they illustrate two diverse routing 
embodiments contemplated by the present Inven- 
tions In both embodiments, signals are encoded as 
digital. data packets, and each packet includes a 
routing code. Moreover, this routing code is desir- 

55 ably communicated using a relatively small amount 
of data, such as seven or eight bits. For each call, 
constellation 11 (see FIG. 1) may deliver thousands 
of such data packets. Thus, the use of only a few 
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routing bits in eacli data packet saves network 
resources connpared to implementations tiiat re- 
quire more elaborate routing codes. 

In one embodiment of the present invention, 
referred to below as a space region embodiment, 
the routing code Identifies the space region 26 to 
which the data packets are directed. In this space 
region embodiment, all nodes 12 include sufficient 
Intelligence to route data packets to a node 12 
serving the identified space region 26. Once the 
data packet arrives at the indicated satellite or 
node 12, the data packets are passed on to the 
earth, either by this node 12 or by a neighbor node 
12. The entities setting up a call and participating 
in the call need not be aware of the precise nodes 
12 used in delivering data packets or of changes in 
the identities of ihese nodes 12 over the course of 
a call. 

In another embodiment of the present inven- 
tion, referred to below as a physical node embodi- 
ment, the routing code identifies a particular 
switching node or satellite 12 which serves as the 
tormina! node for the data packets communicated 
by a call. In this physical node embodiment, all 
nodes 12 include sufficient intelligence to route the 
data packets to this terminal node. Since nodes 12 
do not move significantly with respect to one an- 
other, only a minor amount of Intelligence is re- 
quired. On the other hand, as the terminal node 
changes over the course of a call, the change in 
identity of the terminal node is communicated back 
to the party originating the data packets. This phys- 
ical node embodiment relies exclusively on the 
satellite jurisdiction indicated by circles 24 and 
does not use space regions 26. 

FIG. 3 shows a block diagram of a switching 
node, for example a satellite 12, used by constella- 
tion 11 (see FIG. 1). In the preferred embodiment 
of the present invention, all nodes 12 have a similar 
structure. Node 12 includes any number of tran- 
sceivers. For example, one transceiver 28 may be 
included for each cross link 16 (see FIG. 2). In 
addition, node 12 may include any number of 
earth-link transceivers 30, where each earth-link 
transceiver 30 serves a single CSC 18 or GCS 20 
(see FIG: 1). Node 12 may additionally include a 
subscriber-unit transceiver 32. Node 12 commu- 
nicates with any number of subscriber units 22 
(see FIG. 1), potentially in the thousands at any 
given instant, through transceiver 32. Each of tran- 
sceivers 28-32 couples to corresponding antennas 
34-38, respectively. 

. Each transceiver 28-32 may include various 
sub-components common in the art, as illustrated 
in connection with cross-link transceiver 28a and 
subscriber unit transceiver 32. For example, each 
of transceivers 28-32 may include a receiver 40 
and a transmitter 42. Each receiver 40 couples to 



an input buffer 44, into which input data are placed 
after the data are received at node 12 and de- 
modulated. For subscriber transceiver 32, input 
buffer 44 may be divided so that an individual sub- 
5 buffer is provided for each of the numerous chan- 
nels served by transceiver 32. Each transmitter 42 
couples to an output buffer 46, from which data are 
obtained for modulation and radiation or broadcast-, 
ing away from node 12. For subscriber transceiver 
70 32 output buffer 46 may be divided so that an 
individual sub-buffer is provided for each of the 
numerous channels served by transceiver 32. 

Transceivers 28-32, along with various memory 
components and a timer 48, couple to a processor 
IS 50. Processor 50 may be implemented using a 
single processor or multiple processors operated in 
a parallel architecture. Generally speaking, proces- 
sor 50 coordinates and controls transceivers 28 so 
that node 12 receives data communications from 
20 cross links 16, appropriately distributes the re- 
ceived communications among output buffers 46. 
and transmits the communications back out into 
cross links 16. Data communications are also re- 
ceived from and transmitted to the surface of the 
25 earth via transceivers 30-32. Timer 48 is utilized to 
synchronize processor 50 and node 12 with timing 
constraints imposed by network 10 (see FIG. 1). 

The memory components of node 12 are con- 
figured to include a logical channel identification 
30 (LCID) table 52. Table 52 associates LCID values, 
discussed below, with output buffer addresses of 
transceiver 32 in a one to one correspondence. 
The addresses included in table 52 directly cor- 
respond to a channel used to transmit cpmmunica- 
35 tions to a subscriber unit 22, In other words, by 
writing data in the output buffer 46 of transceiver 
32 at the location specified by an address in LCID 
table 52, a particular traffic channel assigned to a 
particular subscriber unit 22 is selected. 
40 The nriemory components are further config- 

ured to include a routing look up table (RLUT).54, a 
neighbor service -map or list 56, a routing code 
table 57, and other memory 58. Generally speak- 
ing, RLUT 54 contains one data element for each 
45 possible routing code that may be received in a 
data packet at node 12. The data element asso- 
ciated with a data packet's routing code identifies 
which cross link 16 (see FIG. 2) to use in routing 
the data packet away from node 12 to its intended 
50 location. Alternatively, the data element may inform 
node 1 2 that the data packet has reached its In- 
tended destination. 

Neighbor service map 56 records LCID values 
assigned to calls for which neighbor nodes 12 are 
55 new terminal nodes, status data characterizing the 
traffic carrying capacity of the cross links 16 to 
those nodes, and which CSOs 18 and GCSs 20 
(see FIG. 1) being served by those nodes. New 
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terminal nodes are nodes to which data packets 
have been handed in the physical node embodi- 
ment of the present invention. RLUT 54 and map 
56 are discussed in more detail below. 

Routing code table 57 associates LCID values, 
routing codes, and addresses of input buffer 44 for 
multichannel transceiver 32 in a one-to-one cor- 
respondence. The addresses included in table 57 
directly correspond to a particular channels used in 
up-linking data packets to node 12. Node 12 may 
append the LCID values and routing code to the 
data packets before transferring the packets to 
another entity In network 10. The routing code and 
LCID values are initially determined during call 
setup, preferably by a CSO 18 (see FIG. 1), and 
sent to node 12 in a network control message. In 
accordance with the physical node embodiment of 
the present invention, the routing code is repet- 
itively updated during the course of a call in accor- 
dance with network control messages received 
from nodes handling opposing ends of the calls. 

Other memory 68 includes data which serve as 
instructions to processor 50 and which, when ex- 
ecuted by processor 50. cause node 12 to carry 
out procedures that are discussed below. Memory 
58 also includes other variables, tables, and 
databases that are manipulated due to the opera- 
tion of node 1 2. 

FIG. 4 shows a flow chart of a Background 
procedure 60, which is performed by node 12 to 
support the switching of data packets from any 
input buffer 44 to an appropriate output buffer 46 
(see FIG. 3). In the preferred embodiment of the 
present invention, all nodes 12 perform substan- 
tially the same procedure. Background procedure 
60 may be viewed as running continuously while 
nodes 12 isimultaneously engage in other activities. 
Generally speaking, procedure 60 determines 
whether certain needs have arisen, then takes an 
appropriate action when the needs are detected. 

The flow chart shown in FIG. 4 is constructed 
primarily from the perspective of the space region 
embodiment, discussed above, of the present in- 
vention. Many tasks depicted in FIG, 4 may be 
omitted for the physical node embodiment of the 
present invention. On the other hand, the few tasks 
which may be omitted for the space region em- 
bodiment are illustrated in FIG. 4 with double-lined 
boxes. 

Procedure 60 performs a query task 62 to 
determine whether one or more new RLUTs 54 
(see FIG. 3) need to be generated for use by node 
12, The space region embodiment of the present 
Invention utilizes different RLUTs 54 to track the 
movement of nodes 12 over space regions 26 (see 
FIG. 2). Accordingly, a number^ for example 1 0- 
100, of different RLUTs 54 are used every orbit, 
and each orbit's set of RLUTs 54 differs from the 
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set used in the previous orbit. Rather than con- 
sume an extensive amount of memory storing 
RLUTs 54 that are not being used, the present 
invention generates RLUTs 54 before they are 

5 needed. RLUTs 54 that are no longer needed may 
be overwritten in the memory of node 12. Accord- 
ingly, task 62 determines when a need for generat- 
ing a new RLUT 54 exists. 

The need to generate a new RLUT may be 

10 determined in accordance with a variety of factors. 
For example, task 62 may determine that a new 
RLUT 54 needs to be generated a predetermined 
period of time before the new table will be used by 
node 12. Alternatively, task 62 may queue the 

75 generation of a new RLUT 54 when a stockpile of 
existing RLUTs 54 falls below a predetermined 
size. Or, task 62 may decide that all RLUTs 54 to. 
be used in an upcoming orbit need to be generated 
when a node is over a polar region of the earth 

20 where communication traffic is low and node 12 
may easily spare processing power for the genera- 
tion of RLUTs 54. These and other considerations 
pertinent to the efficient operation of node 12 may 
be relied upon in task 62 to determine when a 

25 need exists for generating one or more new RLUTs 
54. 

When task 62 detects the need for generating 
one or more RLUTs 54, a task 64 generates the 
one or more RLUTs 54 and saves them in the 

30 memory of node 12. Task 64 may be performed 
immediately after task 62, or may be performed 
later in a separate process which has been queued 
by task 62. Each single RLUT 54 associates a few 
bits of data with each possible space region 26 

35 (see FIG. 2). The data saved in RLUT 54 represent 
a link identifier (ID). The link ID specifies which of 
cross links 16 (see FIG. 2) to use in routing a data 
packet to the space region identified by a routing 
code. Alternatively, the link ID may inform node 12 

40 that the data packet might have reached its des- 
tination space region and that perhaps no cross 
link 16 should be used to transfer a data packet 
away from a node 12. 

The precise algorithms used to generate 

45 RLUTs 54 are not critical to the operation of the 
present invention. For example, a node 12 may 
simulate the position of itself and its neighbor 
nodes in constellation 11 with respect to all space 
regions 26 (see FIG. 2) at a representative point In 

50 time for the RLUT 54 being generated. Then, node 
12 may. for simulated data packets routed to all 
possible space regions, determine the shortest or 
most direct path from the simulated position. Alter- 
natively, node 12 may receive data from a control 

55 station, such as GCS 20 (see FIG. 1), which can be 
expanded, to generate one or more RLUTs 54. 
Furthermore, nothing prevents the generating al- 
gorithms from incorporating special case rules. For 

6 
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example, routing algorithms may be configured to 
slightly favor in-plane routing over cross-plane rout- 
ing and even to weigh this bias toward favoring in- 
plane routing differently at polar latitudes when 
compared to more equatorial latitudes. 

Background procedure 60 performs a task 66 
to determine whether a need exists for switching 
from a currently used RLUT 54 to a new RLUT 54. 
Preferably, a single RLUT 54 is activated for a 
predetermined period of time, for example one to 
ten minutes. Task 66 may desirably determine 
when this predetermined period of time has ex- 
pired. When task 66 detects the need to switch 
between RLUTs 54, a task 68 saves a variable in 
the memory of node 12 which causes the next 
scheduled RLUT 54 to become the activated RLUT 
54. 

For the space region embodiment of the 
present invention, an appropriate RLUT 54 is ac- 
tivated at regular Intervals, RLUTs 54 are gen- 
ei'ated in advance and are ready and waiting to be 
activated when they are needed. A continuous 
stream of RLUTs 54 tracks the movement of node 
12. Tasks 62-66 may, but need not, be omitted In 
connection with the physical node embodiment of 
the present invention. The physical node embodi- 
ment routes data packets to specified physical 
nodes 12. The relative orientation of nodes 12 
remains static. Consequently. RLUT 54 may re- 
quire only minor changes during normal operations 
in connection with the physical node embodiment 
of the present Invention. In the physical node em- 
bodiment, RLUT 54 may, for example, be gen- 
erated off-line and communicated to node 12 via a 
GCS 20 (see FIG. 1). 

Background procedure 60 performs a task 70 
to determine whether a need exists for processing 
a hand-off directive. A hand-off directive represents 
a message received from a neighbor node 12. The 
message informs a node 1 2 that the neighbor node 
sending the message has been a terminal node for 
one or more calls identified by the directive. As a 
terminal node, the neighbor node has been routing 
data packets associated with the one or more calls 
to one or more terminating units on or near the 
earth, such as subscriber units 22, CSOs 18, or the 
like. The hand-off directive also informs the node 
12 receiving the directive that the neighbor node is 
moving out of range for the terminating units and 
that the node 12 receiving the directive will, at 
some nearby point in time, be serving as the 
terminal node for the one or more calls. 

When task 70 detects a need for processing a 
hand-off directive, a task 72 takes an appropriate 
responsive action. Task 72 may be performed im- 
mediately after task 70 or later in a separate pro- 
cess which has been queued by task 70. When 
calls associated with subscriber units 22 (see FIG. 
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1) are being handed off, task 72 may store logical 
channel identification (LCID) values in LCID table 
52 and in routing code table 57 (see FIG. 3). An 
LCID value is a tag which each data packet In a 

5 call carries to uniquely identify the call, to identify 
the subscriber unit 22 to which the data packet is 
directed, and to identify a CSO 18 (see FIG. 1) 
which has some connection with the call. LCID 
values are discussed in more detail below. By 

10 saving LCID values in LCID table 52 and call rout- 
ing table 57, node 12 assigns channels to the LCID 
values. 

When calls associated with CSOs 18 (see FIG. 
1) are being handed off, task; 72 may store the 
76 identity of the CSOs in neighbor service map 56. 
By saving these CSO IDs in map 56, node 12 can 
send the bulk messages to the new terminal node 
which will assign a particular earth-link transceiver 
30 (see FIG. 3) to communications with the handed 

20 off CSOs- 

The responsive actions taken by task 72 may 
additionally include the communication of a mes- 
sage back to the neighbor node to Inform the 
neighbor node of new channel assignments for the 

25 calls of the subscriber units 22 (see FIG. 1) being 
handed off. The neighbor node may then inform 
the terminating units of the new channel assign- 
ments and a scheduled time for handing off to the 
new node 12. Handing off Is relevant to routing 

30 data packets for both the space region and phys- 
ical node embodiments of the present Invention 
because routing procedures, discussed below, 
compensate for the hand offs In delivering data 
packets to the nodes 12 which act as terminal 

35 nodes for calls. 

Background procedure 60 performs a task 74 
to determine whether a need exists for processing 
one or more neighbor service update messages. 
Neighbor service update messages convey LCID 

40 values of the calls for which the neighbor node 
serves as a new terminal node. The service update 
message may Inform a node 12 of a neighbor's 
new acquisition of a channel or release of a pre- 
viously active channel. Channels may be acquired 

45 when, for example, a call has been recentiy setup 
or terminated or a call, has been handed off. 

In either of the space region or physical node 
embodiments of the present invention, the neighbor 
service update messages convey link status data. 

50 The link status data characterize the ability of a 
neighbor node to process traffic data received over . 
a common cross link 16 (see FIG. 2). The status 
- data may indicate that a cross link 16 has failed, 
that the neighbor node is experiencing exception- 

55 ally heavy data traffic and has a reduced capability 
to process new data traffic, or that normal cbmmu- 
nrcation can take place. These status- data are used 
in the present invention to prioritize data, packet 

7 
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vice map 54 is kept current through the commu- 
nication of neighbor service update messages, dis- 
cussed above in connection with Background pro- 
cedure 60 (see FIG. 4). In connection with the 
physical node embodiment of the present inven- s 
tioh. neighbor service map 54 is kept current 
through the recording of hand-off data, as dis- 
cussed above in connection with task 90 (see FIG. 

After task 140. a query task 142 determines io 
whether a serving neighbor node was found. If no 
neighbor node serving the LCID value 102 has 
been found, a task 1 44 drops the packet 96 or sub- 
packet 110, and program control proceeds to task 
1 38 to process the next sub-packet 1 1 0 or packet 75 
96. In dropping the packet 96 or sub-packet 110. 
task 144 may advantageously maintain statistics on 
dropped packets 96 and sub-packets 110. 

When task 142 determines that a serving 
neighbor node has been found, a task 146 alters 20 
the routing code to indicate this neighbor node. 
Task 146 is optional for the space region embodi- 
ment of the present invention because the neighbor 
node presumably shares service of a common 
space region 26 (see FIG. 2) with the node 12 25 
performing procedure 118. On the other hand,- in 
the physical node embodiment of the present in- 
vention, task 146 will cause the neighbor node to 
determine that it might be the terminal node for the 
data packet 96 or sub-packet 110. 30 

After task 146, a task 148 moves the packet 96 
or sub-packet 110 to the output buffer 46 asso- 
ciated with the cross link 16 (see FIG. 2) to the 
indicated serving neighbor node. Task 148 may 
advantageously re-format a sub-packet 110 into a 35 
packet 96 prior to placing It in the output buffer 46. 
The packet 96 will automatically be sent to the 
appropriate neighbor node in due course. After task 
148, program control proceeds to task 138 to pro- 
cess the next sub-packet 110 or packet 96. 40 

In summary, the present invention dynamically 
routes communication signals. The dynamic nature 
of the present invention allows physical nodes 
through which communication signals are routed to 
change during the course of a call. A minimal 45 
amount of network resources are dedicated to rout- 
ing communication signals. A relatively small rout- 
ing code is included in each data packet being 
delivered through the constellation of nodes, and 
routing is performed, at least in part, based upon a so 
table look up operation that utilizes only a relatively 
small amount of memory. Moreover, the present 
invention distributes routing decisions among net- 
work nodes. Consequently, it instantly and auto- 
matically responds to data traffic congestion and 55 
link failures, and automatically corrects for incorrect 
routing decisions. Furthermore, the present Inven- 
tion disposes of data packets quickly to minimize 
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delay in delivering communication signals between 
network entry and exit points. 

The present invention has been described 
above with reference to preferred embodiments. 
However, those skilled in the art will recognize that 
changes and modifications may be made in these 
preferred embodiments without departing from the 
scope of the present invention. For example, those 
skilled in the art will appreciate that the particular 
tasks discussed herein may be sequenced dif- 
ferently than described. Moreover, the precise tim- 
ing, orbital geometry, network topology, data code 
lengths, and other parameters discussed herein are 
presented as illustrative examples and are not to 
be viewed as limiting the scope of the present 
invention. These and other changes and modifica- 
tions which are obvious to those skilled In the art 
are intended to be included within the scope of the 
present invention. 

Claims 

1. A method of routing a signal through a switch 
which serves as one node (12) in a constella- 
tion (11) of switching nodes, said method com- 
prising the steps of: 

receiving a data packet (96) having a rout- 
ing code (100) therein, said data packet repre- 
senting at least a portion of said signal; 

obtaining a link identifier (16) in response 
to said routing code, said link identifier specify- 
ing one of a plurality of communication links 
useable at said switch in routing said data 
packet away from said switch; and 

transmitting said data packet away fronn 
said switch over said one communication link. 

2. A method of routing a signal through a con- 
stellation (11) of switching nodes (12), said 
signal being delivered between two points that 
move with respect to said constellation, and 
said method comprising the steps of: 

receiving a data packet (96) at a first node 
of said constellation, said data packet having a 
routing code (100) and a logical channel iden- 
tification (LCID) value (102) therein, and said 
data packet representing at least a portion of 
said signal; 

seriding said data packet to a second node 
of said constellation, said second node being 
identified in response to said routing code; 

determining (116), at said second node, 
whether said second node might be a terminal, 
node for said data packet, said determining 
step being responsive to said routing code; 

evaluating (134), when said determining 
step determines that said second node might 
be said terminal node, said LCID value to 



23 EP 0 563 572 A2 24 



determine whether a logical channel identified 
by said LCID value is served by said second 
node; and 

transmitting (148), when said second node 
does not serve said LCID value, said data 
packet away from said second node toward a 
neighbor node over a second communication 
link determined in response to said LCID val- 
ue. 



A data packet switching node for routing a 
signal within a constellation (11) of switching 
nodes (12), said switching node comprising: 

a receiver (40) configured to receive a data 
packet having a routing code (100) therein, 76 
said data packet representing at least a portion 
of said signal; 

means, coupled to said receiver, for ob- 
taining a link identifier (102) in response to 
said routing code, said link identifier specifying 20 
one of a plurality of communication links usea- 
ble at said switching node in routing said data 
packet away from said switching node; and 

a transmitter (42), coupled to said means 
for obtaining, for transmitting said data packet 25 
away from said switching node over said one 
communication link. 
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(54) Dynamic signal routing 

(57) Data packets are delivered through a constella- 
tion (1 1) of nodes (12) to a termination unit (18. 20. 22). 
The node where a packet leaves the constellation is a 
terminal node. Each packet includes a routing code. 
When a node receives a packet, it examines the routing 
code to determine if that node might be the packet* s ter- 
minal node. A table look up operation is performed using 
the routing code as an Index to a routing table. The table 
Identifies a link (16) to use in routing the packet away 
from the node to a neighbor node. The packet is also 
examined to verify compatibility between packet type 
and a selected link. When a node concludes that it might 
be a terminal node for a packet, it evaluates a channel 
identifier to determine if it is currently serving the party 
to whom the packet is directed. 
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